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Abstract 

A comparison of Landin’s form of lambda calculus with 
Church’s shows that, independently of the lambda calculus, 
there exists a mechanism for converting functions with ar¬ 
guments indexed by variables to the usual kind of function 
where the arguments are indexed numerically. We call this 
the “lambda mechanism” and show how it can be used in 
other calculi. In first-order predicate logic it can be used to 
define new functions and new predicates in terms of existing 
ones. In a purely imperative programming language it can be 
used to provide an Algol-like procedure facility. 

Categories and Subject Descriptors D.1.1 [Applicative 
(Functional) Programming]', D.3.1 [Formal Definitions 
and Theory ]; D.3.3 [Language Constructs and Features ]; 
F.3.2 [Semantics of Programming Languages]; F.3.3 [Stud¬ 
ies of Program Constructs] 

Keywords Lambda Calculus, Predicate Logic 

1. Introduction 

Lambda in programming languages Though “lambda” 
was used to name functions in the first Lisp, this does not 
imply that this language conforms to the lambda calculus: 
none of the early Lisps had lexical scoping. This shows that 
lambda is a mechanism that exists independently of lambda 
calculus. 

Let us call “functional programming” the use of a pro¬ 
gramming language based on lambda calculus. In 1967 
Landin described |14j], ISWIM, the first programming lan¬ 
guage based on lambda calculus. PAL 0] and POP-2 01, 
which were based on ISWIM, became the first implemented 
functional programming languages . It was followed by 
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many such languages, of which Scheme, Haskell, and the 
various forms of ML are the most widely known in computer 
science circles. A more recent phenomenon is that there are 
widely used languages, such as JavaScript and Python, of 
which many users don’t even know that there is a subset 
allowing functional programming. 

The most important lesson of functional programming 
is that problems are often more easily solved functionally 
rather than imperatively. Yet at times it seems essential to 
program imperatively. Monads are a way to combine func¬ 
tional and imperative programming. We are interested in 
other ways of enriching imperative programming, if not by 
including lambda calculus, then perhaps with the lambda 
mechanism. 

The lambda mechanism with predicate calculus Floyd’s 
verification method fH] leads to an intricate entanglement 
of imperative code with logic formulas, which suggests 
using logic itself as a programming language. This is of 
course what happens in logic programming, an approach that 
amounts to the use of a particular theorem prover as execu¬ 
tion mechanism. Because of its highly specialized choices, 
logic programming does not exhaust the possible uses of 
logic as a programming language. 

Independently of logic programming one sees the follow¬ 
ing promising features of first-order predicate logic for use 
as a programming language: 

1. Both functions and predicates. 

2. Simple mathematical semantics that is adaptable to on¬ 
tologies familiar to program specifiers. 

3. Potential for defining new functions in terms of existing 
ones. 

4. Potential for defining new procedures in terms of existing 
ones. 

One of the goals of this paper is to show how to realize 
the potential in items [3] and [4] by means of the lambda 
mechanism. 

The lambda mechanism for Algol-like languages Proce¬ 
dure calls in Algol 60 with by-name parameters have a re¬ 
semblance to beta reduction in lambda calculus. This sug- 


l 


2015/6/1 


gests reformulating procedure definition and procedure call 
by means of the lambda mechanism. In this way a transition 
is made from a purely imperative language to one that shares 
features with a functional programming language. 


2. Notation and terminology 


We denote the cardinality of a set V by | V|. For a finite V 
with V = n, we freely confuse the finite cardinals with the 
corresponding ordinals and loosely refer to them as “natural” 
numbers. As a result, locutions such as “for all i £ n” are 
common as abbreviation of “for all* £ { 0 ,..., n — 1}”. 

The set of all functions from set S to set T is denoted 
S —^ T, so that we may write / £ (S —> T). To relieve the 
overloaded term “domain” we call S the source and T the 
target of S —>■ T and of any / belonging to it. 

\S —>• T\ = |T|I s L Therefore, when \S\ = lwe have that 
\S->T\ = \T\. 

The value of / at x £ S is written as /(x) or as f x . 
The composition h of /£(£'—>■ T) and g £ (T —» U) 
is denoted g o f and is the function in S —> U defined by 
x !-)■ g(f(x)) for all x £ S. 

Tuples are regarded as functions. The tuple t £ (n —> S), 
with n a natural number, can be written as (to,, t n -x). 
The tuple t is said to be “indexed by” n. Tuples can also 
be indexed by other sets. For example, consider a tuple 
/ £ ({x, y, z} ->• {0,1}) specified by f(x) = 0, f(y) = 1, 
and f(z) = 0. We may use instead the tabular representation 

of this tuple: / = ■ 


X 

y 


0 

l 

0 


Consider the set I —» D of tuples. Any subset of it is 
called a relation, and its type is 2 1 ~ JfD . I is the index set of 
the relation. An n-ary relation is a subset of n —> D, where 
n is a natural number. A function / £ (D —» D) defines the 
binary relation {(d,/(d)) | d £ D}. Consider a relation p of 
type 2 —>• D such that (x, y) £ p and (x, y') £ p imply that 
y = y'. Such a relation is called a partial function. “Partial 
function” might suggest a special case of “function”, but it 
is the other way around. 


3. The lambda mechanism 

The tuple form of lambda notation Landin introduced 
ifTl what we shall call the tuple form of lambda notation. 
The distinction can be introduced by an example. Consider 
the lambda calculus expression 

\x 0 ■ ■ ■ \x n -i . M (1) 

In lambda calculus abstraction happens one variable at a 
time; in this example it is repeated n times. The n vari¬ 
ables are assumed distinct; assuming otherwise leads to 
strange phenomena. For example, according to floh . Defi¬ 
nition 1.22, (XxXx.M)N rewrites according to ^-reduction 
to [N/x] (Xx.M), the result of substituting N for x in Xx.M. 
According to [10], case fd) in Definition 1.11 applies. This 


case states that [Nfx](Xx.P) = Xx.P, so that (XxXx.M)N 
/3-reduces to Xx.M. 

The counterpart of (0Q) in the tuple form of lambda nota¬ 
tion is 

X(x 0 ,...,x n -i) . M (2) 

It is a single abstraction on an n-tuple of distinct variables. 

The application of 0} in sequence to Mo,..., M„_i is 
written as 

(... ((Ax 0 • ■ • Xx n -i . M)M 0 ). ■ ,)M n _i). 

The application of (O to (Mo,..., M„_i) is written as 

(A(x 0 ,..., x„_i) . M)(M 0 , ■■., M„_i). 

An example of the lambda mechanism Any lambda ex¬ 
pression with free variables can be used to specify a func¬ 
tion. Suppose we are interested in functions over a domain 
D. The lambda expression x(yy) specifies a function in the 
sense that, if domain elements are given as values for x and 
y, then x(yy) is exactly one element of D. The assignment 
of domain elements to these variables is a function of type 
{x,y} —> D. In this sense x(yy) defines a function and 
that function is of type ({x, y} D) —> D. In symbols, 
[x(t/t/)J £ (({x, y} —> D) —»• D ). Such a function is called 
a “binding” by Burstall and Lampson 0. 

Suppose now that we want to use x(yy) to define a two- 
argument function / £ ( D 2 —> D). We can’t identify / with 
[x(yt/)] because they are of different types. We need a kind 
of adapter that converts type {x, y} 1) to type D 2 D. 

Such conversions are effected by lambda abstraction in the 
tuple form of lambda calculus. 

In this example we have that [A(x, y).x(yy)\ £ ( D 2 —>• 
D), whereas [x(t/j/)]j £ (({x, y} —>• D) —> D): two 
different expressions have denotations of different types. 

In general, for a lambda expression M with set X of 
free variables we have [M] £ ((X —>• D) —> D) and 
|A(xo,... ,x„_i).M] £ (£>I A 'I —>• D), assuming that 
Xo,..., x n -i is one of the n! enumerations of the n variables 
in X. The conversion of [M] to [A(xo,..., x n _i).M] we 
call the “lambda mechanism”, which is at work in the tuple 
form of lambda calculus. It converts an expression denoting 
a function in (X —>■ D) —» D) to one denoting a function in 
D\ x \ -> D. 

Mathematicalformulation of the lambda mechanism Given 
an expression E with finite set X of n free variables. Let I), 
the domain, be a set. Let x be a function in X —> D (in short, 

X £ (X —> D)), let x £ (n —> A'), and let d £ (n —> D) be 
such that d(i) = x(x(i)) for all i £ n. See FigureQ] 

The lambda mechanism is the use of A in any of the 
following three situations. 

1. Lambda used to transform tuple x to tuple d: d = Xx-X- 
This is nothing but another way of writing the functional 
composition d = x° x - We come even closer by writing 

d = X',X 
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X 



Figure 1. d = x ° x - 

which is the way some authors write the functional com¬ 
position of x and x- 

The fact that in the tuple form of lambda notation there 
can be no repeated variables in 

x = (x 0 ,... 

translates to the existence of the inverse of x regarded as 
a function. Thus we can write d = \ ° x equivalently as 
X = d ox -1 ; see footnot^U. 

2. A natural extension of a transformation of a tuple to a 
tuple, as in item Q] is to transform a set of tuples of the 
same type to a set of tuples of the same type. That is, a 
transformation of a relation to a relation when we think 
of a relation of type A —> B as a subset of A —> B. In 
our situation, from P C (X —> D) to Q C (n —y X) so 
that A x.P = Q with Q = {A x.p \ p £ P}. 

This use of lambda is similar to the one found in Section 
9.3 of £1]]. 

3. Another natural extension of item [Q is a transformation 
from a function / £ (X —> D) D to a function 
g £ (n —> D). As in itemQ] we have that d = \x-X- 
Suppose that / and g are related by fix) = g(d) for all 
X £ (X —>• D). Then we have g(Xx.x) = fix) f° r all 
X £ (X —> D). As extension to functions of the lambda 
mechanism, we write instead g = A x.f. 

4. Predicate logic as programming language 

A functional programming language is one that is based on 
the lambda calculus or on combinatory logic. Similarly, a 
logic programming language would be one that is based on 
predicate logic. The attraction of the latter is that logic is 
more popular for program specification than lambda calcu¬ 
lus. 

1 It has been suggested Gi to write this as \ = A 1 x.cl, but this may be 

going too far. 


Pure Prolog is a programming language, and it is based 
on first-order predicate logic. It is a special case in several 
ways: it is based on the clausal form of logic, it presupposes 
execution by a particular resolution theorem prover, and 
its data domain is the Herbrand universe of the program. 
The last restriction is lifted in the Prologs that are used in 
practice, and this has compromised its relation to logic. 

The fact that pure Prolog is based on a thin slice of 
logic and its tenuous relationship to practice suggest that we 
consider anew the potential of first-order predicate logic as 
a programming language. 

Logic has a lot going for it as starting point for a pro¬ 
gramming language. It has function symbols denoting func¬ 
tions and predicate symbols denoting relations. Variable-free 
terms denote objects and variable-free formulas denote truth 
values. Among the things that are lacking are facilities to de¬ 
fine new functions and relations in terms of existing ones. In 
this section we describe how these facilities can be added by 
means of the lambda mechanism. 

4.1 Semantics of logic formulas 

According to an interpretation /, an //-ary function symbol 
/ denotes an //-argument function 1(f) over a universe of 
discourse D. An n-ary predicate symbol p denotes a relation 
I(p ) consisting of n-tuples of elements of D. 

DEFINITION 1. The meaning M 1 of variable-free terms and 
formulas under interpretation I is defined as follows. 

• M 1 (c) = 1(c) if c is a constant. 

• M\f(t o,..., t„_r)) = (/(/))(Af 7 (f 0 ),..., M 1 (t n -\))) 
if f is a function symbol. 

• q(t 0 ,.. .,t k -i) is true in I iff (XI 1 (t 0 ),. ■. i)) £ 

I(q) if q is a predicate symbol. 

• A conjunction Eq A ■ ■ • A E n _\ of formulas is true in I iff 
Ei is true in I for all i £ n. 

• A disjunction Eq V • ■ ■ V E n _i of formulas is true in I iff 
Ei is true in I for at least one i £ n. 

• A formula that is the negation of E is true in I iff E is not 
true in I. 

We regard the formula “A if B ” true if and only if A is 
true or the negation of B is true. 

We now consider meanings of formulas with a set V of 
free variables, possibly, but not typically, empty. Let a be 
an assignment , which is a function in V —> D, assigning 
an individual in D to every free variable. In other words, a 
is a tuple of elements of D indexed by V. As meanings of 
expressions with variables depend on a, we write M 7 for 
the function mapping a term to an element of the universe D 
and for mapping a formula to a truth value. 

Definition 2. Af 7 is defined as follows. 

• Af 7 (f) = a(t) ift is a variable 

• Af 7 (c) = 1(c) if c is a constant 

• Mi(f(to,..., tn- 1)) = (I(f))(MM,..., M 7 (f„_r))). 
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q(to ,..., tk—i) is true or false in I with a according to 
whether (M^(t 0 ),..., M^(t k - 1 )) is in I(q). 


defined as binary relations. We will see that relations can be 
defined recursively. 


Now that satisfaction of atoms is defined, we can con¬ 
tinue inductively with satisfaction of complex formulas. 

• A conjunction Eq A • • • A E n _ i is true in I with a iff Ei 
is true in I with a, for all i £ n. 

• A disjunction Eo V • • • V E n -\ is true in I with a iff Ei 
is true in I with a, for at least one i £ n. 

• If E is a formula, then 3x.E is true in I with a iff there 
is a d £ D such that E is true in I with ct x \d where u x \d 
is an assignment that maps x to d and maps the other 
variables according to a. 

• If E is a formula, then Wx.E is true in I with a iff for 
all d £ D, E is true in I with a x \d where a x \d is an 
assignment that maps x to d and maps the other variables 
according to a. 

DEFINITION 3. Let F be a formula with set V of free vari¬ 
ables. We define 

M ! (F) = {a £ (V -A D) | Mi{F)}. 

4.2 Defining new functions in terms of existing ones 

So far, I has assigned meanings only to variable-free terms. 

This is now extended as follows to terms with free variables. 


DEFINITION 4. Ift is a term with set V of variables, then 
M 1 (t) is the function of type (V —> D) —A D that maps 
a £ (V -t- D) to Ml(t) £ D. 

EXAMPLE 1 . D is the set of natural numbers and I is an 
interpretation in which /(+) is addition and J(x) is multi¬ 
plication. 


(M I (x + y x z))( 


X 

y 

Z 

1 

2 

3 


= 7. 


EXAMPLE 2. D is the set of natural numbers and I is 
an interpretation in which /(+) is addition and /(x) is 
multiplication. The term x + y x z of Example Q] can 
be used to extend I with function symbol f by defining 
1(f) as A (x,y,z).M I (x + y x z) and by defining 1(g) 
as A (y, z, x).M I (x + y x z). With these extensions of I we 
have (M I (f))( 1,2,3) = 7 and (M I (g))( 1,2,3) = 5. 

4.3 Defining new relations in terms of existing ones 

The reason why Definition 0 rules out recursivity is that 
the function symbols denote total functions. Cartwright 0] 
responds to the need for recursive definitions by restricting 
the domain of discourse to those that are partially ordered 
with a unique least element that is interpreted as undefined. 

Our response to the need for recursivity is to represent 
partial functions via predicate symbols as relations. In this 
way there is no need to change the generality of allowing 
any domain of discourse, partially ordered or not. With¬ 
out changing the classical semantics of first-order predicate 
logic, n-ary relations of a given type are partially ordered as 
sets of tuples and include the empty tuple. Because of this 
the possibility of defining new relations from existing ones 
is more important than that of defining new functions. Here 
also the lambda mechanism is used. 

Predicate logic does not provide a facility for defining 
new relations. To make up for this deficiency we introduce 
“predicate extensions”. 

Syntax of predicate extensions 

DEFINITION 6. Let an interpretation I be given. A predicate 
extension is a set of expressions containing, for j £ k 

(k >0), 


Tabular tuple notation is explained in Section [2] 

Thus we see that a term t with set V of free variables 
can be used to define a function in (V —» D) —> D. 
However, we cannot use this to define the meaning of a new 
function symbol, as this meaning has to be a function in 
(\V\ ? 1)) / I). The required conversion can be made 
by the lambda mechanism. 

DEFINITION 5. Let t be a term with set V of variables and 
let (tco, ■ ■ ■, x n -i) be one of the n\ enumerations of the n 
variables in V. Let f be a function symbol that does not 
occur in t and that is not interpreted by I. We define the 
result of extending I to be 1(f) = A(a,’o,..., x n -\).M I (t), 
where the right-hand side is defined by item\3\on page\3\ 

Note that this definition rules out recursivity both directly 
and indirectly via other interpretation extensions. Recursive 
definition of a function has to allow for the possibility that 
the function is not total. In first-order predicate logic func¬ 
tion symbols denote total functions. Partial functions can be 


Pj '•— A(Xj_o• ■ • • ) %j,nj — l)-AT (Fjfi V • • • V Fj^j — i) 

where each of Fj $,..., /■}.„, „i is a possibly existentially 
quantified conjunction of atoms. These expressions satisfy 
the following two constraints: (1) no two of the pj are the 
same predicate symbol and (2) (xj t o, ■ • ■, is an 

enumeration of the free variables in Fjp V • • • V _!■ 

We use in the definition of pj because of the pre¬ 
vailing convention in logic to use “=” to denote the identity 
relation over the domain of discourse. See Example[3] 

EXAMPLE 3. Let an interpretation that I be given that in¬ 
terprets the function symbols = and s. This interpretation 
can be extended to one that gives even and odd mutually 
recursively defined meanings as follows. 

{even := X(x).M I (x = 0 V (3y.x = s(y) A odd(y))), 
odd := A (x).M J (x = s(0) V (3 y.x = s(y ) A even(y)))} 
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Semantics of predicate extensions Predicate extensions 
are syntactic structures that introduce new symbols. The 
intent is to define new relations as denotations of the new 
symbols. As a preparation for such a definition we introduce 
a class of interpretations for which the definition is valid. 

Definition 7. An DFP-set of interpretations for a given 
predicate extension is a set containing interpretations with 
the following properties: (1) have the same domain D (2) 
have the same interpretation for the function symbols of the 
predicate extension (3) have the same interpretation for the 
predicate symbols that occur in the right-hand sides and not 
in the left-hand sides of the predicate extension. 


(Fj) C X(Xj).M I {p(Xj)) (3) 

(4) 

I is a model of P 

(1) Lemma 1 in flill . (2) Monotonicity of A, (3) Defini¬ 
tion of A applied to sets of tuples, and (4) Definition^ □ 


THEOREM 1 . Every predicate extension has a minimal 
model. 


Proof By Theorem 5 in [18], every formula corresponding 
to a predicate extension has a minimal model. By LemmaQ] 
we conclude that every predicate extension has a minimal 
model. □ 


Thus the interpretations of a DFP-set differ only in the inter¬ 
pretations of the predicate symbols occurring in the left-hand 
sides. 

EXAMPLE 4. A DFP-set for Example\3\could have the natu¬ 
ral numbers as domain D, interpret s as the successor func¬ 
tion, and interpret = as the identity relation over the natural 
numbers. 

DEFINITION 8. Given a predicate extension E as in Def¬ 
inition [6] All DFP-sets for E are partially ordered by A 
where Iq A I 1 iff for all predicate symbols p we have 
Io(p) C I\(p). The intersection of Iq and I\ is the inter¬ 
pretation I in the DFP-set for which I(p) = Io(p) n Ii(p) 
for all predicate symbols p in E. 

DEFINITION 9. Given a predicate extension E as in Defini¬ 
tion [6] I in a DFP-set of interpretations for E is a model of 

E iff 

... ,Xj ! n j -i).M I (Fj i0 V • • • V Fj m - 1) C I( P j) 
for all j G k. 

Here A is used according to Item [2] on page [3 and M 1 is 
used according to Definition [3] 

Definition 10. The formula corresponding to a predicate 
extension P as in Definition\6\is the formula Hq/\- ■ ■ AFfk-i 
where, for all j G k, Ffj is 

0■ ■ ' ■ J ^j,nj-l-Pj(,Xjp, . . . , Xj^j — i) if (Pj .0V‘ • -\/Fj^ n j — l) 

This correspondence allows us to use some results from 

III. 

LEMMA 1. Let I be an interpretation in the DFP-set of 
a predicate extension P as in Definition \6\ The formula 
corresponding to P is true in I iff I is a model of P (see 
Definition [9]). 

Proof Let T 3 abbreviate Fjp V • • • V Let Xj abbre¬ 

viate Xj,o ,..., Xj. nj -i. For all j G k: 

Ffj is true in I <=> (1) 

M T (Fj) C M I (p(X j )) (2) 


Example 5. With the interpretation of Example \4\the min¬ 
imal model assigns to predicate symbol “even” (“odd”) the 
set of even (odd) numbers. 

We conclude that for every predicate extension, every one 
of its DFP- sets has a model that is minimal in the partial or¬ 
der. We consider the relations denoted in the minimal model 
by the predicates in the left-hand sides to be the result of the 
predicate extension. In this way we have added to first-order 
predicate logic a method for defining new relations in terms 
of existing ones. Note its use of the lambda mechanism. 

5. The lambda mechanism for Algol-like 
languages 

It is desirable in programming that basic components be easy 
to write and that components can be combined with ease and 
with few restrictions. Functional programming is attractive 
because functions are such components; they are easier to 
combine with fewer restrictions compared to, say, C. 

The unique flexibility of Algol 60 arises from a number 
of features (not orthogonal, nor even disjoint): nested pro¬ 
cedure definitions, procedure calls reminiscent of beta re¬ 
duction, lexical scoping, the call-by-name parameter mech¬ 
anism. In the 1960s processor speed was the bottleneck for 
all computer applications. As a result the magic mix of Al¬ 
gol 60 features was dropped in favour of Pascal and C, which 
allowed compilers to generate more efficient code. 

In spite of mainstream language and compiler develop¬ 
ment going elsewhere, research into Algol-like languages 
continued SEEl. All this work starts with an abstract 
syntax and derives semantic equations from it. Scott do¬ 
mains seem to be necessary even for the purely imperative 
subset of the programming languages considered. 

Here we are interested in investigating an alternative ap¬ 
proach where the purely imperative subset is written in Ma¬ 
trix Code m. Here the semantics is rigorously defined by 
fixpoint methods, but without the mathematical sophistica¬ 
tion of Scott domains. 

We take as starting point a purely imperative language; 
that is, one without any facility for creating functions or 
procedures. We then add a facility for declaring and calling 
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procedures modelled on the one of Algol 60. In the interest 
of simplicity and clarity “function procedures” will not be 
included in the experiment. 

How to arrive at a minimal imperative language? Perhaps 
drop for-statements and arrays from Algol 60? What about 
switches? To bypass such questions we take a radical ap¬ 
proach and appeal to the reader’s intuitive understanding of 
flowcharts and exploit the fact that these can be expressed in 
Algol 60. This allows us to replace the considerable amount 
of detail that goes into specifying the imperative part of Al¬ 
gol 60 by a compact specification of flowcharts, which we 
will leave at an abstract level. 

5.1 Flowcharts without procedures 

5.1.1 Syntax 

“Syntax” may be a bit misleading, but it is a useful label 
to contrast with Section 15.1.21 Semantics. What we are con¬ 
cerned here is abstract syntax, the structure of flowcharts in¬ 
dependent of graphical or textual representation. 

A flowchart is a tuple (D, N, B , T), where 

1. I? is a set of declarations. A declaration allocates a mem¬ 
ory location and associates it with an identifier. This as¬ 
sociation is local to the flowchart. 

2. N is a set of nodes , 

3. B is a set of boxes. A box contains an assignment state¬ 
ment, which has an identifier as left-hand side and an 
arithmetic expression as right-hand side. 

4. T is a set of tests. A test contains a boolean expression. 

The components N, B, and T constitute the body of the 
flowchart. The identifiers occurring in the body have to be 
declared in D. 

Boxes, and tests are structured as follows. A box is a tuple 
{no, a, n\), where no is a node, the entry node of the box, a 
is the assignment statement, and n\ is a node, the exit node 
of the test. 

A test is a tuple {no, b,n\,n 2 ), where no is a node, the 
entry node of the test, b is the boolean expression, n\ is a 
node, the positive exit node of the test, and 77.2 is a node, the 
negative exit node of the test. 

The nodes are not structured. They serve to connect boxes 
and tests by a node being an exit node of a test or box and 
being the entry node of another test or box. No node can be 
the entry node of more than one box. One node, the start 
node, is not an exit node of any box or test. One node, the 
halt node, is not an entry node of any box or test. 

A translation of flowcharts to text can easily be defined. 
No new insights will be gained by presenting one here. We 
will merely assume that one exists. 

5.1.2 Semantics 

Operational semantics Executing the declarations results 
in the creation of the environment which, in the absence of 



Figure 2. Example of a flowchart. Every small filled circle 
represents a node. Two such circles that are connected by 
a line without an arrow represent the same node. They are 
shown separated only for the convenience of graphical rep¬ 
resentation. Boxes are shown as rectangles; tests as ovals. A 
line with an arrow pointing away from a box or test points to 
an exit node of the box or test. A line with an arrow point¬ 
ing towards a box or test comes from an entry node of the 
box or test. The positive and negative exit nodes of a test are 
indicated by plus and minus symbols, respectively. 

procedures, consists only of a tuple of locations indexed by 
indentifiers. 

The state of a flowchart is a tuple ( k,d ) where k, the 
control state , is a node and where d, the data state, is the 
contents of the tuple created by executing the declarations. 

A transition of a flowchart is a change from state {k, d) 
to state ( k',d '). If k is the entry node of a box, then k' is 
the exit node of that box and d' is the result of executing the 
assignment statement of the box starting in data state d. If k 
is the entry node of a test, then d! = d and k' is the positive 
(negative) exit node of that test if evaluation of the boolean 
expression in data state d yields true (false). 

A state is the successor of a state if there is a transition 
of the former to the latter. Every state has a successor except 
for the states in which the control state is the halt nodcQ. 

A computation of a flowchart is a sequence of states in 
which the first state has the start node as control state and in 

2 The operations in arithmetic and in boolean expressions are built-in and 
their executions always terminate. 


6 


2015/6/1 




























which every next state is the successor of the state preceding 
it in the computation. 

The meaning of a flowchart according to operational se¬ 
mantics is the binary relation on data states consisting of all 
pairs (d, d') such that there is a computation beginning with 
(s,d) and ending with ( h,d '), where s and h are start and 
halt nodes, respectively. 

Declarative semantics The declarative semantics of a box 
with assignment a is a binary relation of data states: the set 
of all (d, d') such that executing a with d as data state results 
in data state d'. 

The declarative semantics of a test with boolean expres¬ 
sion & is a pair of complementary subsets of the identity re¬ 
lation on data states, a positive subset and a negative subset. 
The positive (negative) subset is the set of all (d, d) such that 
evaluation of b yields true (false). 

A declarative semantics of a flowchart can be defined 
by means of a matrix M of which the rows and columns 
are indexed by the nodes of the flowchart and of which 
the elements are binary relations over the data states of the 
flowchart. For every box with entry node i and exit node j 
M[j,i\ is the relation denoted by that box. For every test 
with entry node i, positive exit node j, and negative exit 
node k, M\j,i\ is the positive and M[k,i] is the negative 
part of the decomposition of the identity denoted by the test. 
All other elements of M are the identity relation over data 
states. 

The matrix representation of flowcharts shows them to be 
an instance of the “dual-state machines” of JB- Theorem 2 
offil implies that the operational and declarative semantics 
as given here are equivalent; that is, define the same binary 
relation. 

5.2 Flowcharts with procedures 

In Algol 60 procedure calls are reminiscent of substitution 
in lambda calculus. In fact, it is plausible that the lambda 
calculus and Algol 60 share a common origin in informal 
mathematics dating back to at least early 19th century. Con¬ 
sider for example / defined by 

f(J) = £"=1 ij (3) 

In mathematics it goes without saying that 

• the value of <[3j is not changed if the occurrences of i are 
replaced by any other variable, except j, and 

• that such a change is mandatory if (0 is substituted for / 

in £? =1 /(i). 

Similarly we have, in lambda calculus 

Definition 1.11 ( Substitution ) For any M, N , x define 
[N/x\M to be the result of substituting for every free 
occurrence of x in M, and changing bound variables 
to avoid clashes. 

This is from Hindley and Seldin lIToll . where it is followed 
by a precise definition. 


In the definition of Algol 60 |2l we find a similar stipula¬ 
tion: 

4.7.33 Body replacement and execution. Subsequently 
the body, modified in this way, is inserted in place of 
the procedure statement and is executed. If the pro¬ 
cedure is called from a place outside the scope of 
any quantity non-local to the procedure body, then 
any conflicts between the identifiers inserted through 
this process of body replacement and the identifiers 
whose declarations are valid at the place of the pro¬ 
cedure statement are avoided by suitable systematic 
changes of the latter identifiers. 

So far boxes in flowcharts can only contain assignment 
statements. Let us consider adding the possibility that the 
state transition effected by a box is the result of a procedure 
call and that the body of the procedure is a flowchart. 

5.2.1 Using the lambda mechanism 

The idea behind the lambda mechanism is that any expres¬ 
sion with free variables defines a function. Here the term 
“variable” derives from lambda calculus. In the context of 
flowcharts it is prudent to avoid this term, so we use “loca¬ 
tion” for what is usually called “variable” in imperative lan¬ 
guages and “formal parameter” for “variable” in the context 
of the lambda mechanism. 

Thus the idea behind the lambda mechanism that any 
expression with free variables defines a function is rephrased 
in the context of flowcharts to the idea that any flowchart 
where certain identifiers have been designated as formal 
parameters defines a function of which the values are binary 
relations over states. Such a function is called “procedure”. 

The most flexible procedure mechanism would allow any 
identifier in a statement to be designated as a parameter. 
We propose to follow the rule of Algol 60 where this is 
indeed allowed and where the only limitation on procedure 
calls is that the replacement of actual parameters by formal 
parameters has to yield a valid statement. This rule allows an 
identifier in the left-hand side of an assignment statement to 
be a formal parameter and forbids the corresponding actual 
parameter to be anything but an identifier associated with a 
location. 

Definition 11. A procedure is a set of declarations of lo¬ 
cations followed by a set of declarations of procedures fol¬ 
lowed by the body of the procedure. The set of declarations 
of procedures consists of, for all j S k with k > 0, 

Pj — X(xj : o,..., Xj^ nj —f).Pj 

satisfying the following constraints: (1) each of Pj is a 
procedure, (2) no two of the identifiers pj are the same, 
and (3) (Xjp, ..., Xj >nj —i) is an enumeration of the formal 
parameters in Pj. 
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nat X,Y,Z; 
gcdO = A(x,y,z).GO 
gcdl = A(x,y,z).G1 
gcd2 = A(x,y,z).G2 



Figure 3. Procedure main. GO and G1 are the text represen¬ 
tations of the flowcharts in Figure |U G2 is the text represen¬ 
tation of the flowchart in Figure 0 

The body of the procedure is the body of a flowchart, 
except that it may contain identifiers that are not declared 
in the procedure’s declaration. 

Example 6. This example is a complicated way of comput¬ 
ing the GCD of two numbers. It is distributed over four pro¬ 
cedures with mutual recursion between three of them. See 
Figures\3\\4\ and\5\ 

5.2.2 Operational semantics of the procedure call 

The declarations of the procedure (see Definition ITT1) create 
the environment that determines the effect of executing the 
body of the procedure. This environment consists of two 
parts. 

1. A tuple of locations indexed by identifiers. 

2. A tuple of procedures indexed by identifiers. 

The effect of the procedure call is specified when, for 
every data state of the caller, it is determined whether the 
call terminates and, if so, what the resulting data state of the 
caller will be. This is specified by the following steps. 

1. Create the environment for the call. This environment is 
created by adding the callee’s environment to that of the 
caller while omitting declarations in the caller’s environ- 



Figure 4. The procedures gcdO (left) and gcdl (right). Nei¬ 
ther has any declarations. The identifiers x, y, and z are for¬ 
mal parameters. 



halt 


Figure 5. The procedure gcd2. It has no declarations. The 
identifiers x, y, and z are parameters. 
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ment of variables that are declared in the callee’s envi¬ 
ronment. 

2. Modify the body of the procedure. In the body of the pro¬ 
cedure formal parameters are replaced by actual param¬ 
eters after enclosing the latter in parentheses wherever 
syntactically possible. Possible conflicts between identi¬ 
fiers inserted through this process and other identifiers al¬ 
ready present within the procedure body are avoided by 
suitable systematic changes of the identifiers involvetfl 

3. Start execution of the body in the modified environment. 
The quote from j2] on page[7]applies. 

4. In case of termination, restore the environment of the 
caller on termination. 

6. The lambda mechanism in the lambda 
calculus 

We have demonstrated the lambda mechanism in first-order 
predicate logic and in an imperative programming language. 
In both cases the starting point was a base language of ex¬ 
pressions of which the meaning could only be determined 
with the assignment of values to parameters. In predicate 
logic the base language was that of formulas. In the imper¬ 
ative programming language the base language was that of 
flowcharts. In both cases the lambda mechanism made it pos¬ 
sible to define procedures, with partial functions as special 
case. 

With these two examples in front of us, let us consider 
the question whether the lambda calculus is also an instance 
of the lambda mechanism. If so, then there must be a base 
language. What is it in the case of the lambda calculus? 

The reason why the lambda mechanism has not been no¬ 
ticed in the lambda calculus may well be that the base lan¬ 
guage is so small: no constants (in the pure lambda calculus, 
usually the only form that is studied), and, apart from one 
binary operation for application, only variables. Moreover, 
abstraction acts on a single variable. 

When we have a lambda expression N with one free 
variable x, then N by itself denotes a function, and it is 
a function of type ({a;} —> D) —f D when we interpret 
variables as functions of type D —» D. The difference lies 
in the distinction in the argument type {aa} —> D in the 
first case and D in the second case. As stated in Section [3 
|{a;} — > D\ = Thus we see that |{aa} —tD | = |D|. 

In other words, there is a bijection between these two sets. 
This may explain why we ignore the distinction between 
them. 

7. Related work 

Predicate extensions are similar to the relational programs 
of 0. In turn, relational programs are closely related to 
Prolog programs. 

3 From |2j], section 4.7.3.2. 


For the semantics of flowcharts we have relied on the 
theory of dual-state automata, which is the subject of 0. 

8. Future work 

Definition QT| for flowcharts with procedures is similar to 
Definition [3 for predicate extensions. Yet for predicate ex¬ 
tensions we have given a declarative semantics, while this 
is lacking so far for flowcharts with procedures. The reason 
for the difference is that we followed Algol 60 in allowing 
formal parameters to be procedure identifiers, thus making 
flowcharts with procedures a higher-order formalism in the 
sense that predicate extensions stay within first-order predi¬ 
cate logic. 

If one would disallow procedure identifiers as parame¬ 
ters, then it seems that one could use predicate extensions as 
analogy to define models and to show that a unique min¬ 
imal model can be identified as declarative semantics for 
flowcharts with procedures. 

9. Conclusions 

Lambda calculus is usually credited to Church’s 1941 pub¬ 
lication H. In Church’s 1932 paper (fl he introduces a 
lambda notation, but not the lambda calculus. In another in¬ 
stance of the distinction, Landin gives as title of his paper 
III “A correspondence between ALGOL 60 and Church’s 
Lambda-notation”. This paper proposes a mathematical in¬ 
terpretation of the distinction. Because of the added preci¬ 
sion we were emboldened to graduate from mere “notation” 
to the “lambda mechanism”. 

Although the lambda mechanism fails to cover the use of 
lambda notation in Church’s Q|, we show that the lambda 
calculus itself is an instance and that another instance adds a 
facility to first-order predicate logic to define new functions 
and predicates in terms of existing ones, thus bringing logic 
closer to being usable as a programming language. Finally, 
we proposed to base procedures in Algol-like languages on 
the lambda mechanism. 
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